This is the most over-prescribed command in Windows networking. It appears in the first three suggestions of almost every troubleshooting guide, gets run reflexively by support desks, and fixes exactly one category of problem — which is usually not the category the person running it is facing.
That is not an argument against it. When it is the right tool, it is the only tool, and it works instantly. But knowing precisely what ipconfig /flushdns does, and what it emphatically does not do, will save you from the experience of running it repeatedly while the actual problem sits untouched.
What It Actually Does
Windows keeps a local record of recent name lookups so that repeated requests for the same hostname do not require a fresh query every time. This is held by the DNS Client service, and it is a small performance optimisation that operates invisibly.
The command clears that one cache. Nothing else.
To run it, open Command Prompt or PowerShell as administrator and enter:
ipconfig /flushdns
You should see confirmation that the DNS Resolver Cache was successfully flushed. The next time any application requests a hostname, the machine will ask its configured DNS server rather than answering from memory.
In PowerShell, Clear-DnsClientCache does the same job, and Get-DnsClientCache displays the contents.
The Four Caches People Confuse
A great deal of frustration comes from assuming this command clears things it does not touch. There are at least four separate caches involved in name resolution on a typical Windows machine.
- The DNS Client resolver cache. This is what the command clears.
- The browser's own DNS cache. Chromium-based browsers maintain their own, independent of Windows. A page can continue resolving to the old address after you have flushed the system cache.
- The NetBIOS name cache. Legacy, still present, cleared with
nbtstat -R. - The ARP cache, which maps IP addresses to MAC addresses on the local segment. Cleared with
netsh interface ip delete arpcacheorarp -d *.
And beyond your machine entirely, there is the cache on your DNS server, and the caches on every recursive resolver between it and the authoritative source. You cannot clear any of those from a client.
Also worth knowing: the hosts file is not a cache. An entry in C:\Windows\System32\drivers\etc\hosts overrides DNS entirely and survives any number of flushes. If a name stubbornly resolves to the wrong address after everything else has been cleared, check that file. Entries placed there years ago by a developer or an installer are a recurring source of inexplicable behaviour.
When It Genuinely Fixes Something
The command helps in a specific and narrow set of circumstances:
- A DNS record changed and your machine has the old answer. A website migrated to a new server, an internal service moved, a load balancer address was updated. Your cache still holds the previous address until its time-to-live expires.
- A failed lookup is being remembered. This is the big one, explained below.
- After changing DNS servers. The old resolver's answers are still cached; flushing forces fresh queries to the new one.
- After connecting to a VPN, where internal names should now resolve differently than they did on the public network.
- After correcting a hosts file entry, where the incorrect answer is still cached.
- During testing, where you need to confirm what the resolver actually returns rather than what your machine remembered.
Negative Caching: The Real Reason It Works
This is the mechanism behind most successful uses of the command, and it is rarely explained.
Windows caches failures as well as successes. If a lookup returns "this name does not exist," that negative answer is stored too. The intention is sensible — repeatedly asking for a name that does not exist wastes queries — but it produces a specific and maddening symptom.
Suppose a DNS record was missing, and an administrator has just created it. The record now exists on the server. Your machine, however, cached the failure and will continue reporting that the name cannot be found until that negative entry expires.
The fix has been in place for several minutes. Your computer does not know. Flushing the cache is what makes it visible immediately.
This is why the command so often appears to work after somebody else fixed something — and why running it before the fix achieves nothing.
When It Does Nothing
Equally important to know, because running it in these situations wastes time and creates false confidence:
- The DNS server is unreachable. Clearing your cache removes the only answers you had. This makes things worse, not better.
- The name genuinely does not exist. No amount of flushing creates a record.
- The problem is not DNS at all. If a name resolves correctly and the destination does not respond, resolution was never the issue.
- The address is wrong at the server. Your cache is faithfully reflecting a bad record. Fix the record.
- A captive portal is intercepting queries. Common on hotel and public wireless. The interception continues after flushing.
- The browser is caching separately. The system cache is clear and the browser is not.
See the Cache Before You Clear It
This is the genuinely useful habit, and almost nobody does it.
ipconfig /displaydns
This prints the current cache contents — every cached name, its record type, the time remaining on its entry, and the address it resolves to.
Run this before flushing and you learn something. Run it after and you have destroyed the evidence.
What it tells you:
- Whether a problematic name is cached at all.
- What address it is cached as, which may differ from what the server now returns.
- How long remains before natural expiry.
- Whether a negative entry is present for a name you expect to work.
To examine one specific name, pipe the output through find: ipconfig /displaydns | find "example.com". The full output on a busy machine runs to hundreds of entries.
Diagnosing before clearing is the difference between fixing a problem and hoping one goes away.
Understanding TTL: Why the Cache Exists at All
The cache is not arbitrary. Every DNS record carries a time-to-live value set by whoever administers the domain, and that number dictates how long any resolver is permitted to remember the answer.
Typical values and what they signal:
- 300 seconds (five minutes). Short, used where records change frequently or where a migration is planned. Costs more queries, buys flexibility.
- 3600 seconds (one hour). A common middle ground for records that change occasionally.
- 86400 seconds (twenty-four hours). Long, used for stable records such as name servers themselves.
The practical implication for anyone administering a domain: lower the TTL before you change a record, not after. If a record has a twenty-four hour TTL and you change it, resolvers around the world will keep returning the old answer for up to a day, and there is nothing you can do about it from your end.
The standard procedure is to reduce the TTL to five minutes at least one full TTL period before the planned change, make the change, verify it has propagated, and then raise the TTL back. Administrators who skip that first step spend the following day explaining to users that the fix is in place and they simply have to wait.
This also explains why flushing your own cache appears to work while colleagues still see the old address. You bypassed your local copy; theirs is still counting down.
When Flushing Is One Step in a Larger Reset
Occasionally the network stack itself has accumulated corrupted state, usually on machines that have had several VPN clients or security products installed and removed. The full sequence, run from an administrator prompt:
ipconfig /flushdns— clear the resolver cache.ipconfig /registerdns— re-register the machine's record with DNS.ipconfig /releasethenipconfig /renew— obtain fresh addressing.netsh winsock reset— reset the Windows Sockets catalogue.netsh int ip reset— reset the TCP/IP stack.- Restart the machine. The last two commands do not take full effect until you do.
Use this deliberately rather than routinely. It resets configuration that some applications depend on, and occasionally a VPN client or proxy tool needs reinstalling afterwards.
Browser Caches
If a site still resolves incorrectly after flushing the system cache, the browser is answering from its own.
In Chromium-based browsers, navigate to chrome://net-internals/#dns and use the option to clear the host cache. In Firefox, restarting the browser is usually sufficient, or you can clear it through the network settings page.
A quick diagnostic: if nslookup from a command prompt returns the correct address while the browser reaches the wrong one, the browser cache is the culprit.
Other Operating Systems
For completeness, since mixed environments are normal:
- macOS:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder - Linux with systemd-resolved:
sudo resolvectl flush-caches - Linux with nscd:
sudo systemctl restart nscd
Many Linux distributions run no local DNS cache at all, in which case there is nothing to flush and queries always go to the configured resolver.
Clearing the Server Side
If a problem affects multiple machines, clearing individual client caches is treating symptoms one desk at a time.
On a Windows DNS server, Clear-DnsServerCache in PowerShell clears the server's resolver cache. That is often the actual fix when an entire office is receiving a stale answer, because every client is faithfully caching what the server told them.
The diagnostic that points here: several machines all resolving the same name to the same wrong address. That is not a coincidence of client caches. It is one shared source.
The Honest Summary
ipconfig /flushdns is a precise instrument for a specific problem: your machine is holding an answer that is no longer correct.
It is not a general-purpose repair, it does not fix connectivity, and running it reflexively before understanding the symptom is how support calls become long.
The better habit is to run ipconfig /displaydns first, look at what is actually cached, and clear it only when the cache is demonstrably the problem. That takes ten extra seconds and replaces guesswork with evidence.
0 تعليقات